Navigation system

ABSTRACT

A navigation guidance system ( 1 ) is provided which provides direction information from a remote server ( 11 ) to a mobile user unit ( 2 ) for guiding user to a desired destination. The navigation guidance system ( 1 ) maintains time-related models for traffic speeds expected on road segments of a road database. By maintaining such time-related models, the system can more accurately provide the user with road guidance instructions to arrive at a chosen destination by a given time. The system can also provide more accurate route guidance information to a destination over different routes, even during rush hour or at off peak times. These time related models can be changed as a result of changing traffic patterns or as a result of an incident on a road segment. In a preferred embodiment, therefore, the system continuously monitors each calculated route and advises the users of alternative routes or of updated departure or arrival times as appropriate.

The present invention relates to a system and method for providingnavigation assistance to a user for guiding the user from a sourcelocation to a desired destination. The invention is particularly,although not exclusively relevant to a system for providing navigationinstructions to a user via a mobile unit, such as a telephone, includingan estimated departure time for future travel plans.

Systems have been proposed which provide geographical or positiondependent information to a mobile user. Two main types of systems havebeen proposed to date. These include autonomous systems in which a usercomputer unit includes a geographic database which it accesses todetermine the required geographic or position dependent information; andsystems which employ a remote computer unit to determine the appropriateinformation which is then transmitted to the user via for example amobile telephone. The main disadvantage of the autonomous system is thatthe geographic database used to provide the geographic information isstored in the user's computer device and will soon become out-of-date aschanges occur to the geographic landscape. This database must thereforebe updated on a regular basis which is inconvenient for the user andcostly for the service providers. Whilst the system which uses theremote server overcomes this problem, the “client-servers” systemsproposed to date have limited functionality and tend to calculatequickest routes and arrival times based on national speed limits or userdefined preferences for speeds on different types of road. Suchapproximations clearly do not yield the best results in most practicalsituation.

An aim of the present invention is to provide an alternative routeguidance system which can provide improved route guidance information.

According to one aspect, the present provides a navigation guidancesystem comprising: means for storing data defining a road network; meansfor storing data defining traffic speeds along the roads in the roadnetwork at different times; means for receiving data from a userdefining a travel plan including a source location, a destinationlocation and a proposed travel time; and route determining meanscomprising: (i) means for determining traffic speeds for the roads ofthe road network at the proposed travel time; and (ii) means forcalculating a quickest route from the source location to the destinationlocation at the proposed travel time using the road network data and thedetermined traffic speeds for the roads of the road network. Such asystem allows users to get accurate route guidance information forfuture travel plans and can provide users with a required departure timein order to arrive at the destination at a desired arrival time.

Exemplary embodiments of the present invention will now be describedwith reference to the accompanying drawings, in which:

FIG. 1 is a schematic diagram illustrating a navigation system embodyingthe present invention;

FIG. 2 is a partial cut-away view illustrating an interior of a motorvehicle illustrated in FIG. 1, showing a mobile telephone which issupported in a mounting bracket fixed to the motor vehicle;

FIG. 3 is a schematic block diagram of the mobile telephone shown inFIG. 2;

FIG. 4 is a schematic block diagram illustrating the main components ofa navigation control centre which forms part of the system shown in FIG.1 used to calculate a route from a specified start location to aspecified end location;

FIG. 5 a is a speed time plot illustrating a static speed characteristicwhich can be used to define the traffic speed over a road segment;

FIG. 5 b is a speed time plot illustrating a time varying speedcharacteristic which can be used to define the traffic speed over a roadsegment;

FIG. 5 c is a speed time plot illustrating a dynamic change to a speedcharacteristic which can be used to define the traffic speed over a roadsegment;

FIG. 6 is a schematic block diagram illustrating the main components ofa driving instruction generation system which forms part of thenavigation control centre shown in FIG. 1 and which is used to convertthe route guidance information obtained from the system shown in FIG. 4into user understandable instructions;

FIG. 7 is a block diagram illustrating the main components of a routemonitoring system which forms part of the navigation control centreshown in FIG. 1; and

FIG. 8 is a flow chart illustrating the processing steps performed bythe route monitoring system shown in FIG. 7.

FIG. 1 is a schematic representation of a navigation system 1 forproviding a user within a motor vehicle 2 with navigation informationfor guiding the user to a selected destination. The navigationinformation is provided to the user by a navigation control centre 11 inresponse to a request made by the user. In this embodiment, both therequest and the subsequently determined navigation information aretransmitted between the user and the navigation control centre via theuser's mobile telephone 3 (shown in FIG. 2 mounted in a cradle 5 andpowered from the cigarette lighter socket 7), the mobile base station 9and the telephone switching network 12. The navigation control centre 11maintains time-related models for actual traffic speeds expected on eachsection of road in a road database. This allows the navigation controlcentre 11 to be able to provide the user with relatively accurate routeguidance information to a selected destination, even during rush hour orat off-peak times. This also allows the system to be able to calculatemore accurately the time that the user will have to set off from thestarting location to arrive at the destination at a required arrivaltime.

In this embodiment, the user's telephone or vehicle also includes a GPSreceiver for receiving position, speed and course over the groundinformation which it determines from signals received from overheadsatellites 10. This information is also transmitted to the navigationcontrol centre 11 through the telephone link, so that the navigationcontrol centre 11 can track the user's location over the determinedroute and provide the user with updated route guidance information asappropriate. The navigation control centre 11 can receive navigationqueries from a number of different users having mobile telephones 3 (orsimilar communication devices) and can then provide the appropriatenavigation instructions back to the respective user. The type of querythat the navigation control centre 11 can respond to include:

-   i) Where am I?-   ii) Where is the nearest service station, restaurant etc?-   iii) How do I get to Lymington, Oxford, the nearest service station    etc?-   iv) What is the shortest route, quickest route or the most scenic    route to get to town X from my current location?-   v) If I wish to arrive at town X at time T, at what time should I    start from town Y?

In this embodiment, the navigation information transmitted back from thenavigation control centre 11 to the mobile telephone 3 includes voicesynthesised instructions which are output to the user through thespeaker of the mobile telephone 3.

FIG. 3 illustrates in more detail the main components of the mobiletelephone 3 used by the user in this embodiment. As shown, the mobiletelephone 3 includes a telephone transceiver circuit 13 which isoperable to receive voice data from the base station 9 and to transmitvoice data to the base station 9 through the communications aerial 17.The voice data received from the base station 9 is decoded by thetelephone transceiver 31 and output to the speaker 16. Similarly, thespeech signal of the user is converted by the microphone 15 into acorresponding electrical signal which is encoded into voice data by thetelephone transceiver 13 and transmitted to the base station 9 via theaerial 17.

The mobile telephone 3 also includes a central processing unit (CPU) 23,display 19 and keyboard 21. The keyboard 21 allows the user to enter thenumber of the party to be called as well as, for example, any text queryto be sent to the navigation control centre 11. As with a conventionaltelephone, during a dial up operation, the number being entered by theuser is displayed on the display for verification purposes. Once theuser has confirmed the number to be dialled, the CPU 23 passes theappropriate signalling information to the telephone transceiver 13 fortransmission to the base station 9, for setting up the appropriate callconnection. The mobile telephone 3 also includes a memory 31 includingRAM which provides a working memory for the telephone as well as ROMwhich stores user telephone numbers and control software for controllingthe operation of the telephone 3.

As shown in FIG. 3, in this embodiment, the mobile telephone 3 alsoincludes a positioning unit 25 (which in this embodiment is a GPSreceiver) which is operable to receive GPS satellite signals through theGPS aerial 27. The positioning unit 25 provides the CPU with a positionsignal, a speed over the ground signal and a course over the ground(COG) signal, which are constantly updated (every second or so) whilethe mobile telephone 3 has direct communication with a sufficient numberof GPS satellites 10. The mobile telephone 3 also includes an azimuthsensor 29 which provides an indication of the current orientation of themobile telephone 3 relative to some reference bearing, such as North.This orientation information is also passed to the CPU 23 which storesthe information in the memory 31. The stored position and orientationinformation is then transmitted to the navigation control centre 11automatically or when prompted to do so by the control centre 11.

FIG. 4 is a schematic block diagram illustrating the main components ofthe navigation control centre 11 which are used to determine a routefrom a start location to an end location for a given time for the startor end of the journey. As shown, the system includes a call centre 41which acts as the interface between the user and the route calculationsystem. The call centre 41 may be entirely automatic or it may include ahuman operator. As those skilled in the art will appreciate, if the callcentre 41 is to be entirely automatic, then it will need to haveappropriate speech recognition circuitry and/or text processingcircuitry for converting the user's navigation query into appropriatedata which can be processed by the route calculation system. As shown,the call centre 41 also receives an input from a user preferencesdatabase 43 which defines, amongst other things, the preferred format ofthe navigation instructions for each user (e.g. whether distances are tobe output to the user in miles or kilometres). The call centre 41 canalso set user preferences within the database 43 in response to commandsreceived from the user.

In response to receiving a navigation request, the call centre 41outputs the user defined start and end location to a geocoding unit 45which transforms the user defined locations (which may be in terms ofplace names, post codes, telephone numbers etc) into latitude andlongitude coordinates which it passes, together with any defined startor end time for the journey, to a route calculation unit 47. The routecalculation unit 47 then calculates the appropriate route from the startlocation to the end location using data from a road network database 49,data from a traffic database 51 and user preferences from the userpreferences database 43.

The road network database 49 holds data which defines theinterconnectivity of available road segments, the segment length,direction and the road and street name of which the road segment forms apart. In this embodiment, the route calculation unit 47 does notdirectly navigate through the data in the road network database 49,since it generally includes more information (such as the road names andthe like) than is strictly necessary to calculate the route and hence isslower to navigate through. Instead, in this embodiment, a set of graphfiles 53 are generated from the data stored in the road network database49 which define the available road segments, their interconnectivity,their direction and their length. As illustrated in FIG. 9, the roadnetwork database 49 can be updated by data from external data feeds.These feeds may come from, for example, government departments in chargeof road planning when new roads are built or when existing two way roadsget changed into one way roads or vice versa.

The traffic database 51 is associated with the road network database 49and provides an expected traffic speed for each road segment stored inthe road network database at any defined time of day, day of week andtime of year in relation to other factors which may affect the roadspeed such as school holidays, planned roadworks, annual events etc. Inthis embodiment, the traffic database 51 also includes data which is notneeded by the route calculation unit 47. Therefore, in order to speed upthe route calculation process, appropriate road speed data 55 isextracted from the traffic database 51 for use by the route calculationunit 47. The extracted road speed data defines, for each road segment,the road segment's identification (id), the direction of travel alongthe road segment, the time of travel along the road segment and thespeed of the traffic flow for that segment at that time. The routecalculation unit 47 can then use this road speed data 55 together withthe graph files 53 to calculate the quickest route from the specifiedstart location to the specified end location whilst maintaining a recordof the expected time of day during the route using the specified startor end time for the journey, the road speeds and the road segmentlengths.

In this embodiment, the traffic database 51 can be updated permanentlyor on a temporary basis using real time data to allow for temporary roadspeed variations due to, for example, road traffic accidents, roadsignal failures, temporary roadworks etc. In this embodiment, thetraffic database 51 is updated by a traffic data controller 57 whichgenerates the data held permanently or temporarily in the trafficdatabase 51. The traffic controller 57 may receive defined road speedsfrom external sources such as the Automobile Association (AA) or it maydetermine such speeds from data that it receives from external sourcessuch as the Traffic Master System available in the UK. For example, apattern of road speeds observed during daily rush hours may be modelledby the traffic data controller 57 for permanent inclusion in the trafficdatabase 51.

In this embodiment, the traffic data controller 57 is also operable topredict near-future traffic flows (e.g. over the next several hours)based on observed traffic flows or traffic incidents, using predefinedrules. FIG. 5 illustrates various different speed-time characteristicswhich can be stored for each road segment in the traffic database.

In particular, FIG. 5 a shows a constant speed-time characteristic whichis stored for road segments for which the traffic speed does not change.This type of static speed-time characteristic is the type ofcharacteristic that conventional navigation systems employ and isusually defined either by user preferences or by national speed limitsfor the road segment.

FIG. 5 b is a plot illustrating a time varying speed-time characteristicwhich illustrates how the traffic speed over a road segment may varywith time. The speed-time characteristic shown in FIG. 5 b might, forexample, correspond to the speed characteristic for a road segment overa 24 hour period, with the two dips 60, 62 in the characteristicrepresenting morning and evening rush hours during which the speed onthe road segment decreases. In this embodiment, a different speed-timecharacteristic for each day of the year is stored in the trafficdatabase 51 for each road segment defined in the road network database49.

Finally, FIG. 5 c illustrates a temporary speed-time characteristicwhich may be used to model the expected traffic speed on a road segmentafter an observed change in the steady state road segment speed (whichmay occur because of an accident on that road segment). The shape of thecharacteristic shown in FIG. 5 c can be determined in a number ofdifferent ways. For example, the decay shape may be modelled by a simplefirst order model with some predetermined time constant (e.g. 2 hours).A more sophisticated model may be used in order to incorporate otherknowledge of the incident (such as a traffic report issued by thepolice). Further, if the navigation control centre 11 is controlling themovements of a significant number of users into the affected area, thenit may directly influence the traffic in the vicinity of the incident.Consequently, the traffic data controller 57 can determine anappropriate shape for the speed-time characteristic for the various roadsegments based on this additional knowledge of the planned routes ofother road users. In this embodiment, temporary speed-timecharacteristics such as the one shown in FIG. 5 c take precedence overthe daily characteristics stored for each road segment.

As shown in FIG. 4, the output from the route calculation unit 47 is asegment list which comprises an ordered sequence of road segmentidentifications which define the route to be taken from the specifiedstart location to the specified end location. If appropriate, the routecalculation unit 47 will also output the time of arrival at thespecified end location if the user indicates the start time of thejourney or it will output a required start time to the journey if theuser specifies a required arrival time at the destination. The segmentlist 59 is then converted into appropriate driving instructions for theuser.

The main components of the navigation control centre 11 which generatethe driving instructions are shown in FIG. 6. As shown, the systemincludes a driving instruction generator 61 which receives the segmentlist 59 generated by the route calculation unit 47 together with anyuser preferences from the user preference database 43 and data from theroad network database 49 for the roads defined by the segments in thesegment list 59. The driving instruction generator 61 also receives datafrom a signage database 63 and from a landmark database 65. The signagedatabase 63 stores the location and content of signposts that arelocated along the side of the roads defined in the road network database49 and the landmark database 65 stores the locations and characteristicsof various landmarks along the roads defined in the road networkdatabase 49.

In operation, the driving instruction generator 61 receives the segmentlist 59 from the route calculation unit 47 together with any userpreferences from the user preference database 43. Using the roadsegments ids contained within the segment list 59, the drivinginstruction generator 61 retrieves the appropriate roads and junctionsto be traversed for the calculated route from the road network database49. The driving instruction generator 61 also retrieves appropriatesignage data from the signage database 63 and landmark data from thelandmark database 65 in order to generate a list of driving instructionswhich are in a suitable form for output to the user. In this embodiment,the thus generated driving instructions are stored in a travel plandatabase 67 together with the driving instructions for other user'snavigation queries. In this embodiment, the driving instructionsgenerated by the instruction generator 61 are textual instructions whichcan be transmitted to the user's mobile telephone as a text message orwhich can be converted into speech either by a text to speech converteror by a human operator. For example, if the user's query is to obtaininstructions for getting from London Heathrow Airport to Cambridge, thenthe determined driving instructions may be as follows:

-   -   take the Northbound M4;    -   at junction 4 of the M4 turn off on to the M25 towards        Rickmansworth;    -   at junction 27 of the M25 turn off on to the northbound M11; and    -   at junction 13 of the M11 turn off on to the A1303 until you        arrive at Cambridge.

In this embodiment, the thus generated driving instructions are notdownloaded all at once to the user. Instead, the call centre 41 monitorsthe position of the user and provides the appropriate drivinginstructions one at a time to the user as the user progresses along thecalculated route. As mentioned above, this position information isprovided by the GPS receiver located in the user's mobile telephone 3.

As mentioned above, the navigation control centre can process navigationqueries in respect of future travel plans and can provide estimateddeparture times in order to arrive at the selected destination by apredetermined arrival time. However, the road speed data may be updatedafter the system has provided the user with a response to their initialquery. Therefore, in this embodiment, the navigation control centre 11is operable to store each navigation query and the determined segmentlist, driving instructions, departure time and arrival time in thetravel plan database 67 so that each of the travel plans can bere-evaluated in light of updated road speed data. In this embodiment,this re-evaluation does not recalculate a new route given the new roadspeed data, it simply recalculates the arrival time for the previouslycalculated route using the updated road speed data and the previouslycalculated departure time. As a result, the computation can be performedquickly for multiple navigation queries. If the arrival time has changedconsiderably, then an appropriate warning can be given to the user sothat they can change their departure time accordingly.

The main components of the navigation control centre 11 which performthis monitoring function are shown in FIG. 7 and the processing stepsperformed are shown in FIG. 8. As shown in FIG. 7, the system includes aroute monitoring unit 71 which receives, in step S1, the segment list 59together with user preferences from the user preferences database 43 andthe updated road speed data 55. Using this information, the routemonitoring unit 71 calculates, in step S3, the new arrival time at thespecified destination from the user's current position or from thespecified start location and departure time if the user has not yet setoff. The new arrival time calculated by the route monitoring unit 71 isthen output to a comparison unit 73 which compares, in step S5, the newarrival time with the previously defined arrival time 75. The comparisonresult is then output to a decision unit 75 which compares, in step S7,the change in the arrival time with a predetermined threshold value(Th). If the change in the arrival time is less than the threshold valuethen the decision unit takes no action and the processing for this routeends. If, however, the change in the arrival time is greater than thethreshold value (e.g. the new arrival time is half an hour later or halfan hour earlier than the previously defined arrival time), then thedecision unit 75 determines, in step S9, whether or not the user hasalready set off on the route (making reference to the proposed departuretime and the current time provided by the clock 79). If he has not setoff, and the user has specified either a desired arrival time or adeparture time, then in step S11, the decision unit 75 informs the user(via the call centre 41) of an updated departure time (in order toarrive at the destination at the required arrival time) or an updatedarrival time (if the user sets off on the journey at the specifieddeparture time).

In this embodiment, if the decision unit 75 determines at step S9 thatthe user has already set off on route, then it instructs the routecalculation unit 47 to recalculate the quickest route to the desireddestination from the user's current position. If in step S13, the routecalculation unit 47 determines that there is a quicker route, then atstep S15, the decision unit 75 informs the user of the new route andthen the processing ends. If, however, the route calculation unit 47cannot find a quicker route, then in step S17, the decision unit 75informs the user of the delayed arrival time at the specifieddestination.

The above monitoring procedure is repeatedly performed for each“pending” travel plan until the user arrives at the specifieddestination or until the navigation query has been cancelled by the useror by a system administrator. In this embodiment, the interval betweeneach monitoring operation depends on whether or not the user iscurrently on route or whether or not the travel plan is in respect of afuture travel arrangement. In particular, if the travel plan is for ajourney to be taken next week, then the route monitoring procedure isonly performed for that travel plan once every day, until the day ofdeparture. The route monitoring procedure for this travel plan is thenperformed once every hour until the user sets off at which point theroute monitoring procedure is carried out once every minute.

As those skilled in the art will appreciate, the system described aboveoffers a number of advantages over the prior art navigation systems.These advantages are mainly as a result of the system maintaining timerelated models for traffic speeds expected on each road section in theroad database, as opposed to the static road speeds that areconventionally used. As a result, if the time of a journey is known whenthe route is calculated, the expected traffic conditions for thatjourney can be extracted from the traffic database 51 and the quickestroute for such conditions can be calculated more accurately than withthe conventional systems. The system can also keep track of the time ofday during the route calculation, and continue to update the appropriatetraffic conditions for that time of day, which may well change duringthe duration of the planned journey. These calculations then allow thesystem to be able to calculate more accurately the answer to thenavigation query “If I wish to arrive at town X at time T, at which timeshould I start from town Y?”, by performing the route calculation inreverse time starting from the destination at the prescribed arrivaltime.

The system can also determine different routes for a journey during rushhour, or the same journey at off-peak times, and calculate the journeytime appropriately. The system can also accurately plan a journey whichstarts before rush hour and finishes after rush hour—the point on thejourney in which the rush hour is encountered will be determined and theappropriate route taken for those conditions.

Further, as described above, if the system has advised the driver of theneed to start a journey at a certain time, it can subsequently changethis advice on the basis of new traffic data, to instruct the journey tostart earlier or later as appropriate. Further, since the systemcontinually monitors each of the calculated routes and receives positioninformation of each of the users, it can provide real time navigation byaltering the routes (and hence driving instructions) if a road on apreviously calculated route becomes congested or if the user deviatesfrom the calculated route.

Modifications and Alternative Embodiments

A description has been given above of a navigation system employing amobile telephone and a fixed navigation control centre. Rather thanbeing part of a mobile telephone, the navigation system may form part ofa hand held personal digital assistant (PDA), web browser, laptop PC orthe like. Although not preferred, the navigation control systemdescribed above may be provided as an autonomous system within theuser's vehicle. This is not preferred, because of the large amount ofdata that would need to be stored within the vehicle and the need forconstant updating of each user's databases.

In the above embodiment, the navigation control centre received positioninformation for the user from a GPS receiver built into the user'smobile telephone. This enabled the system to be able to track the useralong the calculated route and to warn the user if a new route should betaken or if the user deviates from the calculated route. As thoseskilled in the art will appreciate, the navigation control centre mayobtain the position information from alternative sources. For example,the user may inform the control centre himself of his current location.Alternatively, the position information may be provided from the mobiletelephone network using, for example, the Cursor system proposed byCambridge Positioning Systems Limited. As a further alternative, thesystem may be arranged to estimate the user's current location given thestarting time for the journey, the current time and the road speeds forthe roads along which the user should have travelled. However, this isnot preferred since it is likely to be less accurate.

In the above embodiment, the driving instructions that were generatedwere sent to the user either as text messages or as voice messages. Asan alternative or in addition, the system may transmit a “thumbnail”sketch or map of the route to be taken. This may be transmitted eitheras a bit map or as a series of vectors representing the route to betraversed.

In the above embodiment, the navigation control centre converted thedetermined segment list into a set of user understandable drivinginstructions which were then transmitted one by one to the user whenappropriate. In an alternative embodiment, the driving instructions maybe downloaded at once to the mobile telephone which could then track theuser's progress along the calculated route and issue the drivinginstructions as appropriate. Alternatively still, the calculated segmentlist may be transmitted to an on board computer in the user's vehiclefor processing and conversion into the driving instructions. Such anembodiment would be preferred where the on board computer also includesa database of map data from which a high resolution image of the routeto be traversed can be displayed to the user on a display in thevehicle.

In the above embodiment, an azimuth sensor was provided in the user'stelephone so that the orientation of the telephone can be determined andhence appropriate instructions can be given to the user to identify aninitial direction to travel. If the handset is to be made as simple aspossible, then the azimuth sensor may be omitted. In this case, the usermay have to revert to a more traditional technique of identifying aninitial bearing, such as identifying the intersection of two streets.

In the above embodiment, a single navigation control centre wasprovided. As those skilled in the art will appreciate, severalnavigation control centres may be provided, each operating within adistinct locality of a geographic region. For example, severalnavigation control centres may be provided in and around large citieswhilst one or two may be provided between the cities in more ruralareas. In such an embodiment, the control centres would be arranged tocommunicate with each other so that as a user enters the geographic areaof another navigation control centre, a “handover” procedure can beperformed. In this way, the navigation control centres form adistributed network of navigation centres.

In the navigation control system described above, a road networkdatabase and a traffic database were used to provide information forroute calculation. As those skilled in the art will appreciate, thesedatabases may be provided by third party systems, with the navigationcontrol system only operating to use the data from those databases.

In the embodiment described above, the navigation centre receivesposition information of each user. The navigation control centre canthen track the changing positions and determine the speed of each userover the road segments. It can then use this actual speed data to updatethe road speed data that is used during the route calculations. Further,if the user's mobile telephone employs a GPS type receiver (whichprovides speed over the ground information), then the mobile telephonecan inform the navigation control centre of the user's speed. In thiscase, the navigation control centre does not need to track the user'sposition to determine the speed although it would need the positioninformation to know to which road segment the recorded speed applied.

In the above embodiment, the monitoring system repeatedly recalculatedthe expected arrival time at the specified destination given theproposed departure time and the road speed data. The purpose of thismonitoring was to determine whether or not any changes to the road speeddata would affect any user's travel plans. As those skilled in the artwill appreciate, this can also be achieved by fixing the arrival timeand navigating through the proposed route in reverse time in order todetermine the new departure time. The new departure time can then bedirectly compared with the original departure time and the user warnedaccordingly if it has changed significantly.

In the above embodiment, the system continuously monitored the expectedarrival time of the user at the specified destination and if it changedby more than a predetermined amount, then it gave the user an updateddeparture time. The threshold value used in determining whether or notto warn the user may be set by a system administrator or it may bedifferent for each user and may be defined in the user preferences. Adifferent threshold value may also be used for different travel plansfor the same user if desired.

In the above embodiment, the user input the navigation query from theusers mobile telephone. As an alternative users can input theirnavigation query and receive the navigation instructions through, forexample, an Internet connection to the navigation control centre. Inthis case, when the user is planning the route, the user may use a fixedlandline connection to the Internet. However, during the route, the userwill need to use a mobile communication link between the user and thenavigation control centre.

In the above embodiment, the route calculation unit calculated the bestroute from the specified start location to the specified end location.In an alternative embodiment, the route calculation unit may calculatethe best route together with one or more alternative routes that theuser may take. The system need not inform the user of these alternativeroutes but may simply store them for use if part of the best routebecomes congested. Further, even if the best route doesn't deteriorate,one of the alternative routes might improve sufficiently for it to beworth mentioning. For example, one of the alternative routes might havehad a blockage when the original route was being calculated whichsubsequently cleared and which may offer the user a significantreduction in the journey time. In this case, the system could output tothe user the proposed new route together with the appropriate departureand arrival times.

In the above embodiment, a number of processing units have beendescribed for use in the navigation control centre. As those skilled inthe art will appreciate, these processing units may be dedicatedhardware circuits or they may be computer software modules run on aconventional programmable processor. A computer program or programs usedto configure such a programmable processor to carry out the processingdiscussed above may be in the form of source code, object code, a codeintermediate source and object code such as a partially compiled form,or in any other form. Such computer programs may be stored in a memoryat the time of manufacture of the device or it may be loaded into memoryby either downloading the program file from, for example, the Internetor from a storage medium such as a CD ROM or the like.

1. A navigation guidance system comprising; means for storing datadefining a road network within a geographical area; means for storingdata defining speed-time characteristics for roads of the road network,which speed-time characteristics define traffic speeds along the roadsin the network at different times; means for receiving data from a userdefining a travel plan including a source location, a destinationlocation and a proposed travel time; and route determining meanscomprising: (i) means for determining traffic speeds for the roads ofthe road network at the proposed travel time using said data definingsaid speed-time characteristics; and (ii) means for calculating aquickest route from the source location to the destination locationdefined in the travel plan at the proposed travel time using the datadefining the road network and the determined traffic speeds for theroads of the road network.
 2. A system according to claim 1, whereinsaid proposed time of travel specifies a desired arrival time at thedestination and wherein said route determining means is operable tocalculate the required departure time from the source location in orderto arrive at the destination at the desired arrival time.
 3. A systemaccording to claim 2, further comprising means for updating the datadefining the speed time characteristics for the roads of the roadnetwork.
 4. A system according to claim 3, further comprising means formonitoring the calculated route using the updated road speed data inorder to determine whether or not a new departure time from the sourcelocation is required in order to arrive at the destination at thedesired arrival time.
 5. A system according to claim 4, wherein saidmonitoring means is operable to calculate the expected arrival time ofthe user at the destination based on the original departure time, thecalculated route and the updated road speed data and is operable torecalculate a new departure time if said expected arrival time is apredetermined amount before or after the desired arrival time.
 6. Asystem according to claim 4, wherein said monitoring means is operableto recalculate the departure time in reverse time starting from thedestination at the required arrival time using the calculated route andthe updated road speed data and is operable to advise the user of thenew departure time if the new departure time has changed by apredetermined amount from the originally calculated departure time.
 7. Asystem according to any of claims 4 to 6, wherein said monitoring meansis operable to perform said determination at predetermined timeintervals, until the user arrives at the destination location.
 8. Asystem according to claim 7, wherein said monitoring means is arrangedso that said predetermined time intervals vary depending on a timedifference between a current time and the calculated departure time. 9.A system according to any of claims 4 to 6, wherein if said monitoringmeans determines that a new departure time is required after the userhas set off from the source location, then said monitoring means isoperable to cause said route determining means to try to find a quickerroute to the destination.
 10. A system according to claim 1, whereinsaid proposed time of travel is defined as a specified departure timeand wherein said route determining means is operable to track time fromthe indicated departure time and to use road speed values for each roadalong the calculated route corresponding to the time at which the useris expected to travel on the road as calculated from the specifieddeparture time.
 11. A system according to claim 1, further comprisingmeans for outputting the calculated route and/or the determineddeparture time to the user.
 12. A system according to claim 1, whereinsaid data defining said road network comprises data defining thelocation of nodes corresponding to road junctions and data defininglinks connecting the nodes representing road segments between the roadjunctions.
 13. A system according to claim 12, wherein at least onespeed-time characteristic is stored for each road segment.
 14. A systemaccording to claim 12 or 13, wherein each road segment is stored with asegment identification number and wherein said calculating means isoperable to output a list of road segment identification numberscorresponding to the route to be traversed from the source location tothe destination location.
 15. A system according to claim 14, furthercomprising means for converting said sequence of road segmentidentification numbers into a sequence of driving instructions definingthe road names and road intersection points to be traversed along thecalculated route.
 16. A system according to claim 15, further comprisingmeans for outputting said driving instructions to the user as a set ofspoken or text instructions.
 17. A system according to claim 16, whereinsaid receiving means is operable to receive said travel plan from theuser via a telephone connection and wherein said calculated route isoutput to the user through said telephone connection.
 18. A systemaccording to claim 1, wherein a different speed-time characteristic foreach road of the road network is stored for each day of the week.
 19. Asystem according to claim 1, wherein a different speed-timecharacteristic for each road of the road network is stored for each dayof the year.
 20. A system according to claim 1, further comprising meansfor generating map data for the calculated route and means foroutputting the map data to the user.
 21. A system according to claim 20,wherein said map data comprises graphic map data illustrating the routeto be taken and wherein said output means comprises a graphical display.22. A system according to claim 1, wherein said receiving means isoperable to receive data from a plurality of different users definingtravel plans for each user and wherein said route determining means isoperable to determine a route for each user based on the time of travelof each user.
 23. A navigation guidance method comprising the steps of:storing data defining a road network within a geographical area; storingdata defining speed-time characteristics for roads of the road network,which speed-time characteristics define traffic speeds along the roadsin the network at different times; receiving data from a user defining atravel plan including a source location, a destination location and aproposed travel time; and determining a route comprising the steps of:(i) determining traffic speeds for the roads of the road network at theproposed travel time using said data defining said speed-timecharacteristics; and (ii) calculating a quickest route from the sourcelocation to the destination location defined in the travel plan at theproposed travel time using the data defining the road network and thedetermined traffic speeds for the roads of the road network.
 24. Amethod according to claim 23, wherein said proposed time of travelspecifies a desired arrival time at the destination and wherein saidroute determining step calculates the required departure time from thesource location in order to arrive at the destination at the desiredarrival time.
 25. A method according to claim 24, further comprising thestep of updating the data defining the speed time characteristics forthe roads of the road network.
 26. A method according to claim 25,further comprising the step of monitoring the calculated route using theupdated road speed data in order to determine whether or not a newdeparture time from the source location is required in order to arriveat the destination at the desired arrival time.
 27. A method accordingto claim 26, wherein said monitoring step calculates the expectedarrival time of the user at the destination based on the originaldeparture time, the calculated route and the updated road speed data andrecalculates a new departure time if said expected arrival time is apredetermined amount before or after the desired arrival time.
 28. Amethod according to claim 26, wherein said monitoring step recalculatesthe departure time in reverse time starting from the destination at therequired arrival time using the calculated route and the updated roadspeed data and advises the user of the new departure time if the newdeparture time has changed by a predetermined amount from the originallycalculated departure time.
 29. A method according to any of claims 26 to28, wherein said monitoring step perform said determination atpredetermined time intervals, until the user arrives at the destinationlocation.
 30. A method according to claim 29, wherein said monitoringstep is such that said predetermined time intervals vary depending on atime difference between a current time and the calculated departuretime.
 31. A method according to any of claims 26 to 28, wherein if saidmonitoring step determines that a new departure time is required afterthe user has set off from the source location, then said monitoring stepcauses said route determining step to try to find a quicker route to thedestination.
 32. A method according to claim 23, wherein said proposedtime of travel is defined as a specified departure time and wherein saidroute determining step tracks time from the indicated departure time anduses road speed values for each road along the calculated routecorresponding to the time at which the user is expected to travel on theroad as calculated from the specified departure time.
 33. A methodaccording to claim 23, further comprising the step of outputting thecalculated route and/or the determined departure time to the user.
 34. Amethod according to claim 23, wherein said data defining said roadnetwork comprises data defining the location of nodes corresponding toroad junctions and data defining links connecting the nodes representingroad segments between the road junctions.
 35. A method according toclaim 34, wherein at least one speed-time characteristic is stored foreach road segment.
 36. A method according to claim 34 or 35, whereineach road segment is stored with a segment identification number andwherein said calculating step outputs a list of road segmentidentification numbers corresponding to the route to be traversed fromthe source location to the destination location.
 37. A method accordingto claim 36, further comprising the step of converting said sequence ofroad segment identification numbers into a sequence of drivinginstructions defining road names and road intersection points to betraversed along the calculated route.
 38. A method according to claim37, further comprising the step of outputting said driving instructionsto the user as a set of spoken or text instructions.
 39. A methodaccording to claim 38, wherein said receiving step receives said travelplan from the user via a telephone connection and wherein saidcalculated route is output to the user through said telephoneconnection.
 40. A method according to claim 23, wherein a differentspeed-time characteristic for each road of the road network is storedfor each day of the week.
 41. A method according to claim 23, wherein adifferent speed-time characteristic for each road of the road network isstored for each day of the year.
 42. A method according to claim 23,further comprising the step of generating map data for the calculatedroute and the step of outputting the map data to the user.
 43. A methodaccording to claim 42, wherein said map data comprises graphic map dataillustrating the route to be taken and wherein said outputting stepoutputs the map data to a graphical display.
 44. A method according toclaim 23, wherein said receiving step receives data from a plurality ofdifferent users defining travel plans for each user and wherein saidroute determining step determines a route for each user based on thetime of travel of each user.
 45. A computer readable medium storingcomputer implementable instructions for controlling a processor toimplement the method according to claim
 23. 46. A computer implementableinstructions product for controlling a processor to implement the methodaccording to claim 23 when said instructions product is run on saidprocessor.
 47. A system according to claim 1, wherein said routedetermining means is operable to keep track of the time of day duringthe route calculation and is operable to update the appropriate trafficspeeds for the roads for the time of day as it changes during the travelplan.
 48. A system according to claim 47, wherein said proposed traveltime defines a desired time of arrival at the destination location andwherein said route determining means is operable to perform the routecalculation in reverse time starting from the destination at the desiredarrival time.
 49. A method according to claim 23, wherein said routedetermining step keeps track of the time of day during the routecalculation and is operable to update the appropriate traffic speeds forthe roads for the time of day as it changes during the travel plan. 50.A method according to claim 49, wherein said proposed travel timedefines a desired time of arrival at the destination location andwherein said route determining step performs the route calculation inreverse time starting from the destination at the desired arrival time.